A healthcare marketplace system may provide a transparent health services marketplace with clear descriptions and posted prices. Many health care providers and payers use legacy systems to communicate information to the healthcare marketplace system for a variety of transactions: eligibility checks, claims processing and benefits enrollment. To integrate the healthcare marketplace system capabilities with existing systems in the health care space, it's important that it be able to process massive streams of transactional data related to health care services. The ability to process these transaction streams enables: real-time eligibility checks for quote requests, submitting a claim for a service after paying cash so that the service cost can contribute toward a deductible, and enrolling a consumer in new health benefits so that they might save money on expensive services. Integrating all of these transaction capabilities with the health service marketplace provides consumers with easy access to information to help them make informed decisions concerning their health care spending. It also provides health care providers and payers with more efficiencies so that administrative costs for processing health care transactions approach zero. Without the dynamic transactional data streaming capabilities, consumers would only be able to use the healthcare marketplace system for cash based transactions and would have to consult other systems for insurance based pricing. The dynamic transactional data streaming may provide the best possible user experience for health care consumers and providers participating in the health care services marketplace.
Since many healthcare providers and payers use legacy systems to communicate information for a variety of transactions (eligibility checks, claims processing and benefits enrollment), according to the American Medical Association (“AMA”), administrative costs associated with the processing of health care insurance claims is upwards of $210 billion per year in the United States. The AMA also estimates that as many as 1 in 5 claims is processed inaccurately leading to significant amounts of money lost due to waste, fraud, and abuse. Thus being able to accurately predict whether a claim will be denied before it is submitted to the payer as well as predicting if the claim was accurately paid after adjudication has the potential greatly improve provider's revenue cycle management.
There is a difference between a “denied” and a “rejected” claim, although the terms are commonly interchanged. A denied claim refers to a claim that has been processed and the insurer has found it to be not payable. Denied claims can usually be corrected and/or appealed for reconsideration. A rejected claim refers to a claim that has not been processed by the insurer due to a fatal error in the information provided. Common causes for a claim to be rejected include inaccurate personal information (i.e.: name and identification number do not match) or errors in information provided (i.e.: truncated procedure code, invalid diagnosis codes, etc.) A rejected claim has not been processed so it cannot be appealed. Instead, rejected claims need to be researched, corrected and resubmitted.
While there is a fair bit of literature on using data-driven methods to detect fraud and abuse in healthcare claims, there is relatively little on using these approaches for predicting denials and errors in healthcare claims. Unlike rejected claims which are erroneous due to very wrong information provided in the claim transaction, claims are denied for less obvious reasons.
Common Reasons for Denied Claims
There are many core reasons that a claim is denied. Below are a few pertinent examples of reasons for denied claims:                Delay between claim submission and encounter: Claims will be denied to too long a time period passes between the encounter and the claim submission because payers specify the allowable amount of time between the encounter and when the claim must be submitted.        Mismatched diagnostic and procedure codes: Claims will be denied if the diagnosis code (ICD) does not warrant the billed procedure code (CPT). Frequent itemset mining approaches such as FP-Growth and others can be used to learn positive and negative association rules between the ICD and CPT codes.        Claim Not at billing contracted rate: If a provider accepts a payer's insurance plan, then they are held to a contracted rate for each procedure they provide for the payer's insured patients. Detecting outliers in a payer/provider/procedure tuple could be detected rather easily using linear regression, however there is one catch and that is when the contract rate changes. Thus a system must be able to deal with the concept of drift of contracted rates.        Claim not covered: The procedures performed by the provider are not covered under the patient's insurance. Some circumstances could be caught with an eligibility check.        Patient no longer eligible: A lot of claims are submitted where the patient is, for various reasons, no longer an insured member of the payer's plan. This could be addressed by doing an eligibility request before a claims submission.        Preauthorization required: The procedure required pre-authorization that was not performed beforehand.        Provider is out of network: The provider is not a member of the payer's network.        
The last 3 reasons (patient is not eligible, pre-auth required, and provider is out of network) are kind of moot at the point of claim submission as there is no ability to appeal since the damage is done. These should probably be moved up in the “process” at the time of the encounter to be more effective.
Previous systems have attempted to solve this problem via expert systems. These systems are cumbersome and require extensive domain knowledge.